1. Field of the Invention
The present invention relates to a storage control method in a storage system having a database.
2. Description of the Related Art
For example, in a storage system, which stores a database (hereinafter, DB), there are times when a technique called disaster recovery is employed in preparation for a malfunction. This is a technique in which the data of a certain site is stored in advanced as a replication of another, geographically separate site, and when there is a disaster-caused malfunction at a certain site, work is restored at another site.
Either synchronous remote copying or asynchronous remote copying is carried out between the sites. In synchronous remote copying, data is transferred to a certain site synchronously with the updating of this data at another site. In asynchronous remote copying, data is transferred to a certain site asynchronously with the updating of this data at another site.
According to the disclosure announced in U.S. Pat. No. 5,640,561, with regard to asynchronous remote copying, there is a system, which guarantees that the sequentiality of a data write coincides at the original site (can also be called the primary site) and the duplicate site (can also be called the secondary site), and a system that does not guarantee this. The sequentiality of this data write must be guaranteed in order to avoid a situation in which a transaction-in-progress state remains, making it impossible to guarantee database consistency. The constitution can be such that this sequentiality guarantee is effective for a plurality of disk groups. U.S. Pat. No. 5,640,561 discloses technology for guaranteeing sequentiality for groups of log (journal) disks and DB disks.
In a storage system that stores a DB, DB disks for storing data itself, and log disks for chronologically storing DB update history information can be provided. When the host computer at the primary site fails due to a disaster or other such occurrence, data on a DB disk can constitute a half-finished update state, but the DB update history information on a log disk is restored to its original consistent state when the DBMS (database management system) inside the host computer is restarted (This kind of technology is disclosed in non-patent literature 1). That is, when a host computer fails, update data for a completed transaction is mirrored to a DB disk (roll forward), and update data for a transaction, which was incomplete when a server failed, is cancelled (roll back).
Patent Literature 1: U.S. Pat. No. 5,640,561 Non-patent Literature 1: “Transaction Processing: Concepts and Techniques, by Jim Gray and Andreas Reuter, Morgan Kaufmann Publishers.
A DBMS, in addition to the status related to a transaction (hereinafter, transaction status, for example, commenced or committed), incorporates in a log it prepares the update history of a DB (hereinafter, DB update history, for example, what is written in which block). Thus, even if the primary site fails, the secondary site can restore the DB using the log of the DB update history copied from the primary site to the secondary site.
However, there are times when processing, in which the number of DB updates within a certain time period is greater than a certain number (hereinafter, multi-updating) is carried out. Batch processing can be raised as a typical example of multi-updating.
In batch processing and other such multi-updating, when a log comprising both a transaction status and a DB update history is created every time a DB is updated, the speed of multi-updating slows down.
Accordingly, a method for alleviating this might be to not incorporated at least a DB update history in a log that is created.
However, simply using this method makes log-based DB recovery impossible because the DB update history is not incorporated into the log.